Method to add new software features without modifying existing code

ABSTRACT

A computer-aided method (FIG.  12 ) for developing software by which programmers may implement different features of an application as independent reusable components, even though these features affect the control flows of one another. A programmer may add new features to an application without the labor intensive tasks of examining and modifying existing code. The programmer uses a set of programming language constructs to specify nonprocedural program units, organize the program units into reusable features and integrate several features together into a feature package. An interaction detection algorithm analyzes program units and determines whether there is interaction among program units in a feature and among features in a feature package. The programmer must resolve the interaction, if detected, before the programs can be executed. A run time system specification supports the semantics of the programming language constructs and preserves the conditions that enable interaction detection.

This application is the National Stage of International Application No.PCT/US02/25463 filed on Aug. 9, 2002, which claims the benefit ofpriority under 35 U.S.C. §119(e) of U.S. Provisional Patent ApplicationNo. 60/313,364 filed on Aug. 17, 2001, both of which are herebyincorporated by reference in their entirety.

TECHNICAL FIELD

This invention relates to the field of computer programming languages,the method of using such a programming language, and the procedure toexecute and analyze programs written in such a programming language.

BACKGROUND

This application is a non-provisional application claiming priorityunder 35 U.S.C. §120 to provisional application Ser. No. 60/313,364,filed Aug. 17, 2001 of the same name and to the same inventor as theinstant application.

In software development, the need often arises to add new features to anapplication already implemented with existing code. This is one of themost difficult tasks in software development, especially if the newfeatures will change the execution flow of the original program. Forexample, in a telephone switching system, to add programs to implementthe “call forwarding” feature will change the execution flow of theexisting “plain old telephone service” and other features. To add suchnew features using existing general purpose programming languages, theprogrammer must modify existing code. That requires the programmer to bethoroughly familiar with the existing code and be able to trace, line byline, the different execution flows of existing code to determine whereto make the changes. With existing art, this is a labor-intensiveprocess as there is no automated tool that can help the programmer. Atthe end, the programmer is often left wondering whether she hascorrectly determined the code to be changed, whether she has found allof them and what impact her changes may have on existing functionality.It will require exhaustive testing and many trials and errors before thejob is considered done.

In addition, in large-scale software development, it is often necessaryto assign different programmers to develop different features of anapplication. Using today's general purpose programming languages such asC++ or Java, the programs of “call waiting” will require changes in theprograms of “three way calling” and vice versa as these features affecteach others' control flow. The programmers need to negotiate with eachother thus complicating their design task. Their designs becomeintertwined and the resultant software obscures the logic of theindividual features making them difficult to maintain. Each featurecannot be a standalone library component. They will all be loaded as amonolithic object whether the user desires all of them. Therefore, thereis a need to enable programmers to design their features independentlyand package them as a library of components.

Later, we shall refer to programs that, when they are put together intoa single executing program, one may change the execution flows of theother to be interacting programs. Alternatively, we may say one programinteracts with another, or they interact with each other. Since featureprograms are the programs that implement a feature, when we say twofeatures or two feature programs interact with each other, we mean someprograms of one feature interact with some programs of the other.

Using an existing general-purpose computer programming language, such asC++ or Java, a programmer must sequence the execution flows of programstatements. This makes it necessary to change code when interactingfeature programs must be integrated together. Furthermore, programswritten in existing general-purpose languages are not easy to analyze.Presently, a tool does not exist that can help the programmer toidentify where to add new feature programs into existing code.

BRIEF SUMMARY

We solve these problems by adding several nonprocedural languageconstructs and specifying the way programs written in this language willbe executed and analyzed. The language allows the programmers to writeinteracting feature programs as independent library components. When thefeature programs are packaged together, a tool can automaticallyidentify the conditions where they interact with each other. Theprogrammer can then use facilities provided by the language to resolvethe interactions without changing existing code.

One nonprocedural language construct is program unit that consists of acondition part and a program body part. The program body part isexecuted when the corresponding condition part becomes true. Unlikeusing a conventional procedural language like C++ or Java, a programmerdoes not specify the execution order of program units in a nonprocedurallanguage.

There are some prior art in computer operating systems that partiallymeets similar goals of this invention but for special cases. The streamsfacility in the UNIX operating system allows the programmers toimplement computer communication protocols in different layers of aprotocol stack as different streams modules. If an application calls forit, a programmer can insert or remove protocol modules from a streamwithout changing other modules in the same stream. The streams facilitytakes advantage of commonly accepted protocol architecture, such as thefact that protocols in different layers look at different header fieldsin a message, and enforces a uniform interface among the protocolmodules. However, it is not a general solution to other applications.Another UNIX facility called pipe allows programmers to connect severalprograms together to create new functionality without changing any ofthe programs. But these programs must adhere to an input/output formatof character strings and they must be arranged in a linear ordering suchthat the output of one program becomes the input to the other.

There exist a number of nonprocedural languages designed mainly forArtificial Intelligence applications such as for capturing expertknowledge and even for theorem proving. Because of the differences inpurpose, the structure and facilities provided by these languages arevery different from ours as well as the method of using the languages.For example, none of them requires explicit feature interaction (alsocalled conflict) detection and resolution processes before a programwritten in them is ready for execution. Some of them, such as CLIPS,have mechanisms for programmers to specify the priority of executionwhen the conditions of two or more program units become true at the sametime during execution. But the programmers typically do not know beforehand what other programs may interact with their programs.

Previously, we developed a nonprocedural language specifically fortelecommunication services (U.S. Pat. Nos. 4,695,977, 4,797,575, and4,747,127 granted Sep. 22, 1987, Feb. 23, 1988, and May 24, 1988,respectively, to T. L. Hansen et. al. and entitled “Control of Real-TimeSystems Utilizing a Nonprocedural Language,” “State Control for aReal-Time System Utilizing a Nonprocedural Language,” “CustomerProgrammable Real-Time System,” respectively, all of which are hereinincorporated by reference). However, the structure and facilitiesprovided by that language are very different from the present method asthe prior work was neither sufficiently rigorous to allow automaticdetection of feature interaction nor did it provide facilities for theprogrammer to resolve feature interaction without changing existingcode.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the relationship among model, program units, anchorfeatures, features and feature packages.

FIG. 2 shows an example domain data type.

FIG. 3 shows an example event type.

FIG. 4 shows an example model statement for telephony call processingapplications.

FIG. 5 a shows a common condition statement for a set of program units.FIG. 5 b shows a common event statement. FIG. 5 c shows a common programbody for several condition and event statement pairs.

FIG. 6 shows an example program unit.

FIGS. 7 a and b show example precedence lists and their conversion toprogram units. FIG. 7 a shows an example of converting astraight-precedence list into program units. FIG. 7 b shows an exampleof converting a set of priority-precedence list into program units.

FIG. 8 shows an example feature.

FIG. 9 shows an example feature package.

FIG. 10 shows an example model extension.

FIGS. 11 a and b show a feature extension.

FIG. 12 illustrates a procedure of developing software using thismethod. It shows the parallel development possible with this method.

FIG. 13 gives the flowchart of Algorithm 1, which checks for the simpleinteraction condition between two program units.

FIG. 14 shows the flowchart of Algorithm 2, which checks for whether theconjunction of two simple predicate formulas is satisfiable.

FIG. 15 shows the flowchart of Algorithm 3 which checks for whether aterm in a disjunctive normal form is satisfiable.

FIG. 16 shows the table that associates a domain variable, its locationin the CSR and the set of predicate functions that use it.

FIG. 17 shows the table that associates an event qualifying field, itslocation in the ESRP and the set of predicate functions that use it.

FIG. 18 shows the flowchart of Algorithm 5 that describes the run timesystem at the initial stage of executing a feature package.

FIG. 19 shows the flowchart of Algorithm 6 that describes the run timesystem when it receives an event.

FIG. 20 shows the flowchart of Algorithm 7 that describes the run timesystem when a program unit returns.

FIG. 21 shows an example program unit to handle the exception that theexecution runs into a condition uncovered by other program units in afeature.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

With existing art, when a programmer needs to add new functionality thatchanges the control flow of existing code, the programmer faces twopossibilities. If the implementation language is procedural such as C,C++ or Java, the programmer will have to undergo a labor-intensiveprocess of changing the existing code. If the implementation language isnonprocedural such as CLIPS, the programmer has very little control onhow the new functionality should interact with the existing code.

In the present software development method the programmer develops thenew functionality as a feature. The programmer goes through acomputer-aided process to develop and integrate her feature with otherfeatures. The programmer puts together the set of features to a toolthat will automatically identify the conditions by which these featuresinteract with each other. The programmer then specifies how theseinteraction conditions should be resolved in a feature package. Theoriginal features are not modified and as a result they can be treatedas reusable library components.

Thus, the present method permits the addition of new functionality toexisting code, is an automated means or tool that identifies how theprogrammer should merge the new functionality with the existing code toenable the reuse of components with dynamic execution flow, and makesthe programmer's job easier.

The above software development method is supported with four constituentparts: (1) a software development process; (2) a set of nonproceduralprogramming language constructs; (3) an algorithm to identifyinteraction conditions among feature programs; and (4) a run time systemto execute feature programs written in the programming language.

We will first talk about the language constructs and the softwarecomponents resulting from the use of the language constructs. We thendescribe the software development process followed by the interactiondetection algorithm and the run time system.

Essential Software Components and Language Constructs

An executable application implemented in our programming language is awell-formed feature package. The feature package consists of a set offeatures, program units and possibly other feature packages. Eachfeature is in turn composed of a set of program units and possibly otherfeatures.

A program unit is a unit of execution. It consists of a condition partand a body part. The body part of a program unit is executed when thecondition part becomes true. The body part will carry out someoperations and may call programs written in other languages. Thespecification in the condition part refers to variables defined in amodel.

The model is a representation of the application. It defines a set ofdomain variables and interface events used by programs of the model toimplement the various features of the application. A state variable,such as an enumeration of the IDLE, TALKING and other states of atelephony application, is an example of a domain variable. A message,such as “Termination-request” used in terminating a telephone call, isan example of an interface event.

Features and the feature package are organizing concepts. A featurecontains a set of program units and a feature package contains a set offeatures. One thinks of a feature as functionality, such as “callwaiting” or POTS. A feature package is an application with a collectionof functionality. Whereas a program unit is a unit of execution, afeature is a unit of reuse. A programmer can combine different sets offeatures to compose different feature packages. The programmer can evencreate different feature packages using the same set of features byresolving the interaction among the features differently.

We require that the condition parts of all program units in a feature beexpressed in terms of the variables defined in the same model. Hence wesay that a feature refers to a specific model. We further require thatall features in the same feature package refer to the same model. Inother words, all the programs within a feature package refer to the samemodel. The relationship among these software concepts is illustrated inFIG. 1. This section describes each of these software concepts. We startwith the notion of a model.

Model

A model statement is identified with the keyword Model and a name. Itcontains the definition of domain variables (their initial values) andevent interfaces. They are used to define the condition portion of aprogram unit.

Domain Variables

A domain variable is either of the type BOOLEAN, which specifies thatthe variable can have either the value TRUE or the value FALSE or it isa variable of a domain data type.

Domain Data Type

A domain data type is similar to a class in C++ or Java. In addition todefining a set of data and the operations on the data just as in aclass, a domain data type defines a set of predicate functions and acombination function.

A predicate function operates on one or more variables of the domaintype and returns a BOOLEAN value. For example, the domain data type ofan integer will contain predicate functions that will determine whetheran integer variable is positive, whether two integer variables areequal, whether one integer variable is greater than the other, and soon. We use the following terminology: a predicate function with specificdomain variables is a predicate; a predicate or a domain variable oftype BOOLEAN is an atom; an atom or its negation is a literal.

Given the conjunction of a set of literals of a domain data type, itscombination function returns whether the conjunction is satisfiable. ABOOLEAN formula is satisfiable if there exists an assignment oftruth-values to its literals such that the formula is true. In animplementation, the combination function may take a list of literals asinput. We note that the integer domain data type given as an example inFIG. 2 is almost the same as the integer class given in Page: 8 “The C++Programming Language,” 3^(rd) Edition, B. Stroustrup, Addison-Wesley,1997 except with the addition of a combination function.

Independence Requirement of Domain Variables

We require that domain variables are independent of each other. That is,the value of a domain variable cannot be a function of other domainvariables. In other words, if a domain variable is in the left-hand-sideof an assignment statement, there can be no other domain variable, or aderivative of another domain variable, in the right hand side of thesame assignment statement. Our compiler checks for such a situation.

More on the Combination Function

A straightforward method to implement a combination function wouldgenerate the truth table of the input conjunction but that may result inmany cases. Given the independence of domain variables and theproperties of the predicate functions of a domain data type, one canoften develop efficient algorithms for combination functions.

For example, consider the domain data type of integers and their usualpredicate functions of “equal to”, “greater than”, “greater than orequal to”, “less than”, and “less than or equal to.” These predicatefunctions establish a partial orderings of the domain variables used inthem. The combination function algorithm would order the domainvariables as specified by the predicates and check for contradictionssuch as when a variable is both greater than and less than anothervariable.

Efficient algorithms exist for common domain data types such asenumeration, set, tree and ordered or linked lists.

Event Interface

The interface defines a set of event types. Each event type is given aunique name and a data structure. Some fields of the data structure canbe identified as qualifying variables. Similar to a domain variable, aqualifying variable is either BOOLEAN or is a variable of a domain datatype. FIG. 3 shows the telephony “Termination_request” message as anexample event type. The message carries the calling party's number as aqualifying variable.

An event is sent to an instantiation of a feature package. It may comefrom a program unit in the package or from some program outside of thepackage. A program unit looking for a particular event specifies that inan event statement that is part of its condition part.

FIG. 4 gives an example model for the implementation of telephone callprocessing system.

A model defines the domain of discourse for the specifications in thecondition part of a program unit. The following describes a program unitin more detail.

Program Unit

A programmer uses the keyword unit and a name to identify a programunit. Program units belonging to the same feature have unique names.

Each program unit consists of a condition part and a program body part.

Condition Part of a Program Unit

The condition part consists of a condition statement and an eventstatement.

Condition Statement

The condition statement is a BOOLEAN formula of atoms of domainvariables. In other words, the condition statement is a first orderpredicates formula, except that we do not use the existential anduniversal quantifiers. When the programmer has the need to specifysomething like “there exists an element in a set”, we ask the programmerto specify a predicate function, say non-empty (x), for a domain datatype “set”. We shall later refer to this kind of formula as a simplifiedpredicate formula.

We follow the convention that when an atom that is defined in the modelbut not used in a condition statement, then the value of the atom doesnot affect the truth-value of the condition statement. In other words,the atom is a “don't care.”

Event Statement

The event statement identifies a list of interface event types definedin the model statement of the feature.

Each event in the list may be associated with a BOOLEAN formula, calleda qualification, on the qualifying variable of the event. Hence, this isalso a simplified predicate formula. The event statement is true if theevent is present and the values of the qualifying variables carried bythat event satisfy the qualification. If a qualification is notspecified, the specification is true if the event is present.

As a short hand, the programmer may specify with the key word “any” todenote that the event statement is true given the presence of any eventdefined in the model. The programmer may attach a qualification denotedby “any”. In that case, the event statement is true when given thepresence of any event with qualifying variables that satisfies thequalification.

The programmer may also specify the keyword “null” to denote that theprogram unit is not waiting for an event. As a result, as soon as thecondition statement of the program unit becomes true, the program bodywill get executed.

A condition statement becomes true if its BOOLEAN formula is true giventhe values of the domain variables at the time of evaluation. An eventstatement becomes true if any of the interface events in the list iscurrent and the BOOLEAN formula on its qualifying variable is true. Anevent is current if it has been received, but not yet processed, by therun time system and is considered to be the highest priority event attime of evaluation. We will give a more complete definition of currentwhen we describe the run time system. A program unit is ready forexecution when its condition statement and event statement are bothtrue.

The condition part of a program unit may be specified graphically. Forexample, a condition statement may be specified as a Venn diagram or asa more complex formal system such as the one described in Page: 11 “OnVisual Formalism,” D. Harel, Communications of the ACM, May, 1988.

As a short hand, we allow the programmer to state the common conditionstatement or event statement only once for a group of program units. Theexample given in FIG. 5 a shows two program units with the samecondition statement. The example given in FIG. 5 b shows two programunits with the same event statement. It is also possible that aprogrammer may want to apply the same program body part to differentcondition statement and event statement pairs. We allow a short hand forthis case in which the condition statement will show a disjunction ofthe condition and event statement pairs. An example is given in FIG. 5c.

The Program Body Part

The program body part contains conventional program statements such asassignment statements, procedure calls, iteration statements and so on,including declaration and operation of variables local to the programunit. These local variables may be automatic or static as used in C andC++. An automatic variable is present while the program unit is beingexecuted and disappears once the program unit exits while a staticvariable retains its value after the program unit exits. Programstatements in a program body may update domain variables, send aninterface event within or outside of the model system, or call programsspecified in other languages. FIG. 6 gives an example program unit froma telephony application. It simply specifies that if the telephone is inthe DIALING state and an Onhook event is received, the switching systemshould release the digit receiver and put the telephone in the IDLEstate.

When a program body updates a domain variable or sends an interfaceevent, it may cause the condition part of some other program unit (evenitself) to become true. Because of the combined effect of featureinteraction detection and resolution in the development process and thedesign of the run time system, there is at most one program unit whosecondition part is true at one time. Thus, we have a choice of eithercontinuing to execute the current program body or switching to executethe program unit whose condition part has just become true. We choosethe former. In other words, we consider the execution of a program bodyatomic. Events sent from the current program body are kept in a queue.Only after we exit from the current program body will we evaluate thecondition parts of other program units using the latest values of thedomain variables. We will return to this topic in more detail when wedescribe the run time system.

Program units are written to implement a certain feature of anapplication. We now turn to describing features.

Features

We distinguish two types of features: anchor features and supplementaryfeatures. An anchor feature provides a starting point for anapplication. A supplementary feature adds new functionality to theapplication. Using telephony as an example again, the program units thatimplement the plain old telephone service (POTS) would be organized asan anchor feature while program units that implement the 3-way callingservice would be organized as a supplementary feature.

Special Requirement for an Anchor Feature

We require that the condition part of at least one program unitbelonging to an anchor feature is true with respect to the initialvalues of the domain variables defined in the model.

Special Requirement for a Supplementary Feature

A supplementary feature must identify at least one anchor feature and atleast one program unit of the supplementary feature must interact withone program unit of every anchor feature that the supplementary featurerefers to.

The compiler can check for both requirements. We will later describe thealgorithm to determine whether two program units interact with eachother for the supplementary feature requirement. Checking the anchorfeature requirements is straightforward.

In the following, we describe the notion of anchor feature in detail.When we describe supplementary feature, we will only highlight how it isdifferent from an anchor feature.

Anchor Feature

A programmer identifies an anchor feature by using the keyword AnchorFeature and a name. An anchor feature consists of two parts: a referencedeclaration and a program units' list. A feature may accept a list ofpass-by-value arguments that are only used by program units within thefeature.

Reference Declaration

Here the programmer declares the model used by the feature. In addition,the programmer may declare and initialize local variables that are usedonly by program units within the feature as well as for the arguments.Space for these variables is allocated when the feature package iscreated until the feature package exits.

Program Units' List

The program units' list identifies the program units that belong to thefeature. The programmer does not specify the execution flow of theprogram units, but may specify the precedence for a subset of theprogram units belonging to the feature.

Precedence of Program Units

Two program units are said to have a precedence relationship if they areordered for execution when both of their condition parts become true atthe same time. The precedence relationship is specified in a precedencelist. If there are several program units in a precedence list, therelationship among the program units is a partial ordering.

One can design various kinds of precedence lists that preserve theprecedence relationship among program units. For example, astraight-precedence (P1, P2, P3) for program units P1, P2 and P3 impliesthat if the condition parts of P1 and P3 are true, only the program bodyof P1 will be executed. On the other hand, a priority-precedence (P1,P2, P3) implies that if the condition parts of P1 and P3 are true, thenthe program bodies of P1 and P3 will be executed in the order specified.

A program unit may appear in more than one precedence list. As a result,two program units that are not in the same precedence list may stillhave a precedence relationship. It is possible that the programmer mayspecify contradictory precedence relationships such as specifying P1precedes P2 in one list but implying P2 precedes P1 in another list.Since all precedence lists specify partial orderings, the compiler cancheck for such contradictions. Algorithms in doing so are well known,e.g. see D. E. Knuth, “The Art of Computer Programming, Volume 1,Fundamental Algorithms,” Addision-Wesley Publishing Company, 1973.

The semantics of precedence lists may also lead to contradiction. Forexample, suppose that we have straight-precedence (P1, P2, P3) andpriority-precedence (P1, P3, P4). When the condition portions for bothP1 and P3 become true at the same time, the straight-precedence listrequires execution stops after P1 but the priority-precedence listrequires execution to continue for P3. Therefore, the design of aprecedence list should be accompanied with an efficient method ofdetermining semantic contradictions.

Writing a Precedence List as Program Units

One can rewrite a precedence list as a collection of program units asfollows. The condition statement of the new program unit is thedisjunction of the condition and event statement pairs of the programunits in the list. Its program body contains conditional statements thatwill execute the appropriate program bodies of the program units in thelist. An example is given in FIG. 7( a) for a straight precedence listand in FIG. 7( b) for a priority precedence list.

What we are saying is that a collection of program units and aprecedence list may be made equivalent.

Program Unit Interaction and Well-Formed Features

Two program units belonging to the same feature interact with each otherif and only if they do not have a precedence relationship and theircondition parts can become true at the same time. Later we will give analgorithm to detect feature interaction.

In our system, if interaction among two program units is not resolved,the run time system will not be able to determine which program toexecute when both of their condition parts become true. There are anumber of ways a programmer may resolve the interaction among twoprogram units such as putting them in a precedence list and rewritingtheir condition parts. A feature that has no interacting program unitsis called a well-formed feature.

Supplementary Feature

A programmer identifies a feature with the keyword Supplementary Featureand a name.

A supplementary feature is similar to an anchor feature with threeexceptions. (1) A supplementary feature must identify its anchor featurein its reference declaration. (2) A feature is not required to have thecondition statement of some of its program units to be true given theinitial values of the domain variables. (3) A supplementary featureshould be reachable from its anchor feature. Feature A is reachable fromfeature B, if after B is invoked, there exists a computation that willlead to some program units in A getting executed. A necessary conditionfor a supplementary feature to be reachable from the anchor feature isthat there exists a program unit in the anchor feature and a programunit in the supplementary feature such that the conjunction of thecondition statements of these two program units is satisfiable.

FIG. 8 gives an example supplementary feature. It implements thetelephony feature of “Call-Forwarding”. The example shows the programunits to activate and deactivate the feature as well as the program unitthat will forward an incoming call when the call forwarding number hasbeen specified and the incoming call does not come from theforward-to-number.

A well-formed anchor feature by itself is executable. But typically, theprogrammer would put several features together in a feature package togive an application rich features.

Feature Package

The programmer uses the keywords Feature Package and a name to identifya feature package. The feature package may accept a list of arguments.The arguments are passed by value only.

A feature package contains a reference declaration, and a list ofprogram units.

Feature Package Reference Declaration

In this portion of the feature package, the programmer specifies themodel that is used by all the programs and the list of features includedin the package. The list of features must include at least one anchorfeature and all features in the package must reference at least one ofthe anchor features in the package. The compiler checks for these tworequirements. A feature package may include another feature package inits feature list. The feature package inclusion relationship is apartial ordering. The compiler can efficiently check circular inclusionwhen two feature packages (transitively) include one another.

In addition, the programmer may define the type of arguments and localvariables used by the programs in the feature package.

Feature Package List of Program Units

The list of program units identifies the program units belonging to thefeature package. One important purpose of these program units is toresolve interaction among features. Thus, the list of program units mayinclude precedence lists for program units and precedence lists forfeatures, which are both short hands for program units that resolveinteractions. We already described precedence lists for program units.

Precedence Lists for Features

The programmer uses a precedence list for features to specify precedencerelationship among program units in the different features. If featureF1 precedes feature F2, then if the condition parts of a program unit P1belonging to F1 and another program unit P2 belonging to F2 become trueat the same time, P1 will get executed before P2.

Similar to precedence lists of program units, one may specify differenttypes of precedence lists for features. For example, astraight-precedence (F1, F2, F3) for features F1, F2 and F3 implies thatif a condition part is true for some program units in F1 and F3, theprogram body for the unit in F1 will be executed. A priority-precedence(F1, F2, F3) implies that if the condition part for some program unit inF1 and F3 becomes true, the program bodies of the units in F1 and F3will be executed in the order specified. Precedence list for featuresdoes not change the precedence relationship specified by the precedencelists of the individual features. One can trivially generate the partialordering of all the program units specified by the precedence lists offeatures and program units.

The compiler will be able to check for contradictions in these lists.

Feature Interaction and Well-Formed Feature Package

Two features, F1 and F2, interact with each other if and only if they donot have a precedence relation and a program unit in F1 interacts with aprogram unit in F2. A programmer can resolve feature interaction byputting interacting features, or the interacting program units, in aprecedence list. Alternatively, the programmer can write a program unitfor the feature package on the condition that these two program unitsinteract to resolve the interaction. We do not recommend resolving theinteraction by modifying feature program units.

A feature package is well formed if none of its program units interactswith one another and none of its features interacts with one another. Awell-formed feature package is executable.

FIG. 9 gives an example feature package that combines the POTS,Call-Forwarding and Do-Not-Disturb telephony features together. Theprecedence list gives priority to program units of the feature package,then those of Do-Not-Disturb, Call-Forwarding and finally POTS. BothDo-Not-Disturb and Call-Forwarding may be invoked when aTermination-request event is received. The “interaction-resolution”program unit resolves the interaction by either forwarding the call orreturn do not disturb action depending on whether the calling party is amember of the privileged set.

As time goes on, even a well-designed model may become inadequate. Forexample, the programmer may want to develop voice and data services on atelephone line. The original voice only telephony model will no longerbe sufficient. When that happens, a new model becomes necessary, but theprogrammer may still want to reuse existing feature code implementedwith the original model.

To enable the reuse, our method allows the development of a new modelextending from an old model and new features and feature packagesextending from existing features and feature packages that uses the oldmodel.

Extension

The purpose of extension is to reuse features written for an existingmodel. There are two levels of extension: creating a new model from theoriginal model, and creating feature packages for the extended modelreusing existing features written for the original model.

Model Extension

A programmer may extend the original model by adding new domainvariables or interface events, and by extending the definition ofexisting domain variables or interface events.

When extending the definition of an existing domain variable orinterface event, the programmer may either add new elements to theexisting definition or extend the range of values of the domain variableor qualification. As an example of adding new elements to an existingdefinition, consider the event “Termination-request” of the examplemodel shown in FIG. 3. The existing data structure of the event maycontain only one field, “calling-party”. The extended definition may adda new “type of service” field to identify whether the calling party isrequesting a voice or data connection. As an example of adding the rangeof values of an existing definition, the programmer may add the value“POST-ANNOUNCEMENT” to the enumeration defining the range of values forthe domain variable “state” used in the example model of FIG. 4.

We require that the programmer cannot eliminate existing elements norreduce existing range of values. The programmer uses the followingsyntax to specify extensions to an existing model:

  Model new-model-name extends existing-model-name {     Domainvariables:       /* Definition of new domain variables and/or extensionsto existing domain variable definition */     Interface events:       /*Definition of new interface events and/or extension to existinginterface event definition */   };

In the above statement, Model and extends are keywords andnew-model-name and existing-model-name are the names of the new andoriginal models respectively.

The extended model includes all the domain variables and interfaceevents defined in the existing model. These domain variables andinterface events possibly have new elements or additional value ranges.In addition, the extended model may have new domain variables andinterface events. The new additions and existing definitions are allavailable to program units using the extended model.

FIG. 10 gives an example model extension for voice and data calls builton top of the (voice only) telephone model. The new model extends thevoice-connection STATE domain data type. It adds a new domain variablefor the data connection states and defines new data interface events.

Feature Extension

After the extended model is specified, a programmer may reuse featureswritten for the original model in a feature package for the extendedmodel. To do so, the programmer includes the reused features in thefeature list of the new feature package. The program units of the reusedfeature become program units of the new feature. Precedence relationshipamong the program units of the reused feature is preserved. The newdomain variables and interface events, as well as new variable elementsor extended value ranges, of the new model are “don't cares” to thesereused program units.

The programmer may add conditions on the new domain variables andinterface events to a reused feature by attaching a qualification nextto the feature name in the feature list in the following manner:

Feature: reused-feature {qualification}, another-feature;

A qualification in this context consists of two statements: a conditionstatement and an event list that are specified in exactly the samesyntax as those in a program unit. It modifies the condition part of theprogram units of the reused feature. The list of events in its eventstatement will now include the events specified in the qualification. Ifthe programmer precedes the condition statement of the qualificationwith the symbol AND, the condition statement of the program unit becomesthe conjunction of its original condition statement and the conditionstatement of the qualification. If the programmer precedes the conditionstatement of the qualification with the symbol OR, the conditionstatement of the program unit becomes the disjunction of the twocondition statements. The programmer may attach different qualificationsto different subsets of program units of a reused feature in thefollowing manner:

  Feature: reused-feature {(program-unit1, program-unit2)  {qualification1},     (program-unit3, program-unit4 .. program-unitN){qualification2}};

FIGS. 11 a and b give an example of a feature for the extended model ofFIG. 10 reusing POTS of the original model. The new feature takesadvantage of capability of the extended model for the user to specify aPIN. It then takes advantage of the new POST-ANNOUNCEMENT state of theextended model to verify whether the calling party can enter the correctPIN within 15 seconds.

The Software Development Process

The software development process includes these steps:

(A) The programmers develop a model of the application.

(B) Based on the model, the programmers develop a set of anchorfeatures.

(C) As each program unit of an anchor feature is written, an interactiondetection tool is invoked to check whether the newly completed programunit interacts with previously completed program units. Alternatively,the interaction detection procedure may be invoked to check possibleinteraction after some subset of the program units is completed.

(D) The programmer resolves feature interaction among the program unitsof an anchor feature. When the feature interaction detection tool findsno more feature interaction among its program units, the anchor featureis a well-formed anchor feature. A well-formed anchor feature isexecutable.

(E) Based on the model and one or more anchor features, the programmersdevelop a set of supplementary features.

(F) For each supplementary feature, its programmer applies theinteraction detection and resolution procedure until all interactionsamong the program units of the feature have been resolved, making thefeature a well-formed feature.

(G) The set of well-formed anchor features and supplementary features ofa model are library components. A programmer picks a set of anchorfeatures and supplementary features (later, we shall refer to themcollectively as features) for a feature package.

(H) The programmer invokes a feature interaction detection procedurethat checks whether the set of features included in the feature packageinteract with each other.

(I) The programmer resolves the interactions. After all featureinteractions are resolved, the feature package is called a well-formedfeature package. A well-formed feature package is executable.

This development process is depicted as a flow chart in FIG. 12. We notethat anchor features can be developed independently without requiringchanges to other anchor features. Similarly, supplementary features canbe implemented independently of one another. The integration of featuresoccurs when they are put together into a feature package. Puttingfeatures together in a feature package does not require changing featurecode even though the features may change the execution flow of eachother.

The development process of writing an extended model and its featuresand feature packages is the same process as described earlier.

Interaction Detection

We exercise interaction detection under two occasions. First, we checkfor interaction among program units in the same feature. Second, wecheck whether any program unit in one well-formed feature interact withanother program unit in another feature when both features are puttogether in a feature package. In this section, we describe a procedureof carrying out the interaction detection of two program units.

Program Interaction Condition

Earlier, we defined two programs as interacting with each other if whenthey are put together, one would change the execution flow of the other.Given the semantics of our programming language constructs and the runtime system, one can show that two program units interact with eachother if and only if the condition part of them can become true at thesame time, and they do not have a precedence relationship.

While we can check for the above condition, it involves showing“reachability” which is computationally intensive. We use the followingsufficient condition instead.

Simple Interaction Condition (SIC):

If two program units interact then:

(1) they wait for the same event and the conjunction of theirqualification with respect to that event is satisfiable;

(2) the conjunction of their condition statements is satisfiable; and

(3) they do not have a precedence relationship.

Interaction Detection Algorithm

Given two program units, X and Y, the following algorithm checks fortheir SIC.

Algorithm 1: If (X and Y have a precedence relationship) note 1   thenreturn (no SIC);   else {     if (the event lists of X and Y do notcontain the same events)       then return (no SIC);       else {        for (each common X and Y event) note 2           check (if theconjunction of their             qualification is satisfiable);        if(no conjunction of qualification is satisfiable)          then return (no SIC);           else { check (if theconjunction of note 3             the condition statements of            X and Y is satifiable);             if (not satisfiable)              then return (no SIC);               else (reportconjunction of                 condition statements                 andqualifications as                 SIC conditions);           }       }  }

A flowchart for Algorithm 1 is given in FIG. 13.

To determine whether two program units have precedence relationship(note 1 in algorithm 1) is relatively straightforward. The precedencerelationship is a partial ordering and can be readily determined byanalyzing the precedence lists (see, e.g. D. E. Knuth, “The Art ofComputer Programming, Volume 1” Addison-Wesley Company, for methods ofprocessing partial ordering).

note 2 and note 3 in algorithm 1 identify the need for a procedure todetermine whether the conjunction of two simplified predicate formulas,say M and N, is satisfiable. Algorithm 2 solves that problem

Algorithm 2 Step 1: Derive a disjunctive normal form D(M) of M; Step 2:Derive a disjunctive normal form D(N) of N; Step 3: For each term inD(M), check whether its conjunction with every   term in D(N) issatisfiable; We denote the i^(th) term resulting from   this conjunctionas E(M, N)(i). Step 4: If (none of the E(M, N)(i) checked in Step 3 issatifiable)     then return (conjunction of M and N not satisfiable)    else return (conjunction of M and N satisfiable and with a report      on all satisfiable conjunctions determined in Step 3).

A flow chart of Algorithm 2 is given in FIG. 14.

Given a BOOLEAN formula, the procedure to derive its disjunctive normalform is well known. A disjunctive normal form is written as thedisjunction of a set of components, “C1

C2

. . . Cn”, where each component Ci is a conjunction of literals ornegation of literals, such as “p1

˜p2

p3”.

To evaluate Step 3, we note that the only logical operator used in E(M,N)(i) is the conjunction which is associative. Hence we can rearrangethe literals of E(M, N)(i) according to whether they belong to the samedomain data type. Then for each group of predicate literals, we call thecombination function of its domain data type.

We note further that: (1) The conjunction of the same variable, say A,is given by (A AND A)==A; (A AND ˜A)==FALSE; (˜A AND ˜A)==˜A. (2) Theconjunction of two different BOOLEAN variables is satisfiable as thevariables are independent. (3) A BOOLEAN literal by itself issatisfiable. As a result, we have the following procedure to evaluateStep 3 of Algorithm 2.

Algorithm 3 1. For each E(M, N)(i), group literals belonging to the samedomain data type together. 2. Evaluate each group using their respectivecombination functions, or in the case when they are BOOLEAN variables,look for contradiction. If any group evaluates to FALSE, return (notsatisfiable) else return (satisfiable).

With this, we show a method of detecting the SIC between two programunits.

A flowchart of Algorithm 3 is given in FIG. 15.

Applying Algorithm 1, 2 and 3 together determines whether two programunits interact with each other. If two program units are shown tointeract with each other, step 4 of Algorithm 2 identifies the conditionin which they interact.

Summarizing this section, SIC is a sufficient condition. When twoprogram units are found to have no SIC, then either they belong to thesame precedence list or their condition parts cannot become true at thesame time. This is true for any two program units in a well-formedfeature or feature package.

The Run Time System

The purpose of the run time system is to manage the execution of programunits. Without loss of generality, an executable object in our languageis a well-formed feature package. A program unit in the feature packageis ready for execution if its condition part becomes true unless itbelongs to a precedence list. In the latter case, the precedence list isready for execution. We showed earlier that a precedence list could bewritten as program units. To simplify our discussion, we assume that allprecedence lists have been rewritten as program units. In other words,the feature package contains only program units. Furthermore, since thefeature package is well formed, if the condition statements of twoprogram units can be true at the same time, then their event listscannot be true at the same time.

For simplicity, we describe the run time system for the execution of asingle feature package. Those who are familiar with the art ofmultiprocessing operating systems can easily extend our result to a runtime system that executes several feature packages concurrently.

The fundamental operations of the run time system are relatively simple:First, it initializes the system. Then after initialization and eachtime after it completes the execution of a program unit, it checks forthe arrival of events, updates the domain variables that have beenchanged as the result of executing the program unit and searches forwhether the condition part of any of the program units has become true.There can be at most one such program unit. If there is one, the runtime system will execute it to completion. If not, it waits for anotherevent. When an event comes, it searches for whether the condition partof any program has become true. It repeats these operations until itexecutes an exit command from a program unit.

The following algorithms, however, describe a fairly optimized run timesystem, especially in the operation that searches for a program unitwhose condition part has become true. The performance of a naïve searchoperation degrades rapidly with the number of literals used in thesystem. We use a set of registers and use each bit in the register torepresent a literal, such that the truth value of many literals (as manyas the length of the registers) can be checked at one time.

We first describe the various data structure used by the run time systembefore going through the algorithms.

Data Structures Used by the Run Time System for Program Units Execution

We describe three sets of data. One set is global to all program units.The second set is specific to each event type. The third set is specificto particular program units.

Per Feature Package Data

The run time system maintains a common state register (CSR) whichcontains the truth values of all the distinct literals used in thecondition statements of the program units belonging to the featurepackage. We consider the same predicate function on two different domainvariables (or different sets of domain variables) to be two distinctliterals. Since each of these literals may only have the values of TRUEor FALSE, the CSR uses one bit for each literal. The CSR is dynamicdata. Its value changes when domain variables are updated duringexecution of the feature package.

For efficient processing, the run time system may rely on some staticdata prepared by the compiler. We associate each domain variable withthe set of predicate functions that use it at the corresponding locationin the CSR and the program units that uses the CSR literals in theircondition statement as shown in FIG. 16. When the run time systemdesires, it can use this data structure to easily update CSR and thestatus of the program unit condition statements with the current valueof the domain variables.

Per Event Type Data

For each event in the event queue, the run time system maintains anevent state register (ESR) analogous to the CSR but for eventqualifications. The ESR follows the format of an ESR template (ESRT)generated for all events of the same type. For each event type, weassociate each qualifying field with a set of predicate functions thatuses it and the corresponding location in the ESRT as shown in FIG. 17.Using the table in FIG. 17, when an event of a particular type arrives,it is straightforward for the run time system to generate the values ofits ESR.

For each event type, we maintain a list of program units that refer tothe event type in their event statements.

Per Program Unit Data

For each program unit, we keep two sets of static data generated fromthe feature interaction detection process. One set comes from thecondition statement and the other from the event statement.

First from the condition statement: For each term in the disjunctivenormal form of the condition, we construct a unit condition register(UCR) that records the values of the variables that satisfy the term.Since the variables used in the term are a subset of the variablesrepresented in the CSR, one possible implementation of the UCR will usea vector the same dimension as the CSR and record the values of thevariables in exactly the same position as in the CSR. The values of theother bits in the UCR will be set to FALSE.

Associated with each UCR, we construct a unit mask register (UMR) toindicate the position of the variables used in the term. In other words,the UMR has the same dimension as the CSR and UCR. The UMR has the valueTRUE in the positions corresponding to variables used in the term, andit has the value FALSE in the positions of other variables.

Given a UCR, and its corresponding UMR, we have a simple method todetermine whether the CSR satisfies the UCR as given in Algorithm 4. Wewill state Algorithm 4 more generally because it will be used in anothercontext. Given a register A, each bit of which represents the value of adistinct BOOLEAN variable. Given another register B having the samedimension as A and each bit of A and B in the same position representsthe same variable. If B records the values of variables that willsatisfy a BOOLEAN formula M and another register C represents thevariables used in the formula with TRUE and FALSE otherwise, thenAlgorithm 4 determines whether the values in A satisfy M.

Algorithm 4: 1. Do a bit by bit logical AND operation between A and C,and record the result into a temporary vector of the same dimension. Atthe end of the operation, the temporary vector has a value of FALSE onevery variable not used in the term and the same value as in A on everyvariable used in the term. 2. Do a bit by bit logical EXCLUSIVE ORbetween the temporary vector and B. If the two vectors matches exactly(i.e. the result of the EXCLUSIVE OR is zero for all bits), then Asatisfies M, else it does not.

From the event statement: For each event, we construct eventqualification registers (EQR) and their corresponding event maskRegisters (EMR) analogues to the UCR's and UMR's of the conditionalstatement. One can use Algorithm 4 to determine whether a given ESRsatisfies an event qualification.

Run Time System Algorithms

We are now ready to describe an example run time system. The run timesystem operates on three states: the initial state when the run timesystem is first created, the active state when it is executing a programunit, and the idle state when it is waiting for an event to make thecondition part of some program unit true. Once it is initialized, therun time system is invoked under two situations: when it receives anevent or when the program unit that is under execution returns.

Initial State

When a feature package is created (some programming languages use theterm instantiated) for execution, the operating system will allocatespace for the local variables declared in the feature package and itsfeatures. Given the initial values of the domain variables as specifiedin the model statement, the compiler or the operating system can computethe initial value of the CSR via the data structure shown in FIG. 16.

Since a feature package must contain at least one anchor feature, thereexists at least one program unit whose condition statement satisfiesCSR. Compare this CSR with the UCR and UMR of all program units usingalgorithm 4, we can determine these program units and put them into acurrent list of program units. As mentioned earlier, program units inthe list do not have event lists that can be true at the same time. Atmost one program unit in the list is not waiting for any event. If sucha program unit exists, the run time system will invoke the execution ofthe program unit and transition to the active state. If no such programunit exists, the run time system transitions to the idle state.Algorithm 5 describes this sequence of action.

Algorithm 5 1. Allocate space and initialize the domain variables andlocal variables defined for the feature package, features and programunits in the feature package. 2. Determine the value of the CSR. 3.Determine the set of program units in the current list. 4. If (thereexists a program unit in the current list not waiting for any events) {  Run-time-system-state = active;   Execute the program unit;   } else {  If (event queue is not empty) {     If (there exists an event in thequeue that matches a program unit     in the current list) {    Run-time-system-state = active;     Execute the program unit;    Exit Algorithm 5; }   }   Run-time-system-state = idle;   ExitAlgorithm 5;}

FIG. 18 shows the flowchart for Algorithm 5. Steps 2, 3 and 4 can bedone at compile time.

After the execution of Algorithm 5, the run time system will be invokedunder two conditions: when the run time system receives an event, orwhen the program unit being executed returns.

Algorithm 6 (When the run time system receives an event) If(run-time-system-state == active) {   put event into event-queue;   exitAlgorithm 6; } else {   if ((there exist a program unit in the currentlist is waiting for an     event of this type) and (the value of thequalifying variables of     the event satisfies the event qualificationof the program unit)) {     run-time-system-state = active;     Executethe program unit;    note 1     Exit Algorithm 6;     } else {     putevent into event-queue; exit Algorithm 6;     };   FIG. 19 shows theflowchart of Algorithm 6.

For the statement in note 1, we check whether the value of thequalifying variables of the event satisfies the event qualification ofthe program unit by using Algorithm 4 on the ESR of the event and theEQR and EMR of the event qualification. Since program unit is in thecurrent list, its condition statement is satisfied by the current CSR.There can be at most one program unit that satisfies both conditions andthat program unit is executed.

The event is put into the event queue if some program unit is beingexecuted at the time or when the event does not cause the conditionportion of some program unit to become true.

Algorithm 7 (When the execution of a program unit returns) Step 1: If(some domain variables have been updated) then {     update CSR; updatecurrent list };   If (current list is empty) then system terminated;Step 2: If (event-queue is not empty) {     Select one event from eventqueue that satisfies the event       statement of a program unit in thecurrent list;     If (no such event can be found) {      Run-time-system-state = idle;       Exit Algorithm 7;     } else {      run-time-system-state = active;       Execute the program unit;      Exit Algorithm 7;}     };   } else {     run-time-system-state =idle; /* No program unit selected for execution */     exit Algorithm 7} FIG. 20 shows the flowchart of Algorithm 7.

In Step 1, we update the current list by applying Algorithm 4 to the CSRand the (UCR, UMR)'s of each program unit. The computation associates acertain value of CSR to a set of (UCR, UMR)'s. This can actually be donein compile time, especially if the dimension of CSR is reasonable. Alsoin Step 1, if no condition statement of any program unit is satisfiedgiven a particular value of the CSR, no further computation is possible.

In Step 2, the selection of an event from an event queue can be based onsome user defined criteria such as first event received will be firstselected, or the first in first selected policy supplemented withpriority of the events. When no event in the event queue satisfies theevent statement of the program units in the current list, the systemwill just have to wait for the next event.

In summary, we described a set of algorithms that specify what the runtime system should do when it is first created (Algorithm 5), when itreceives an event (Algorithm 6) and when the execution of a program unitreturns (Algorithm 7). These algorithms preserve two importantproperties. First, the execution of a program unit is atomic. The runtime system does not stop in the middle of executing one program unitand switches to execute another. Second, only one event at a time isprocessed (take out of the event queue) but we leave the choice of whatpriority scheme to use open. These algorithms are example algorithms toshow feasibility. There are other variations and optimizations possible.

CONCLUSION

We described a set of nonprocedural language constructs, a run timesystem to execute program units written in these language constructs, analgorithm to detect interaction among the program units, and a processto develop software using this technology. One main purpose of thepreceding is to show feasibility of enabling programmers to developinteractive features as reusable components and to add new featurewithout modifying existing code. Many topics of interest are outside thescope of what is explicitly described herein, but we will brieflydiscuss two topics: on the performance of the algorithms and on theanalysis of programs written in this language.

The careful reader may note that checking for whether the conjunction oftwo BOOLEAN formula is satisfiable (an essential step in checking forthe SIC, simplified interaction condition) is NP-complete. However,today's computers can resolve this problem reasonably fast (less than aminute) for formula with less than twenty literals. However, ifprogrammers use that many literals in their condition statements, theyare handling something that they themselves may not understand andprobably should avoid. This problem is mitigated in the present methodas we need to deal with this only for program units that wait for thesame events with compatible qualifying field.

The performance of the run time system algorithms as given should bereasonable. It can be further optimized. For example, we mentionedearlier that the compiler could actually do static analyses to linkdifferent values of the common state register (CSR) to different programunits. The run time system can learn and remember the current list ofprogram units for a specific value of the CSR at ran time, so that itdoes not need to determine the current list the next time. The describedalgorithm of manipulating registers is also quite fast.

Note that the domain variables and their predicate functions specifiedin a model actually may define an infinite domain of discourse (forexample, a domain variable is allowed to be of type integer, whichalready is infinite). However, the condition statements of the programunits of a well-formed feature package will divide the domain ofdiscourse into finite number of partitions. If the condition statementof a program unit defines a partition, the number of partitions in afeature package is at most the number of program units in the featurepackage. In other words, a feature package is actually a finite statemachine. All the analysis algorithms investigated for finite statemachines may apply to analyze feature packages.

It is relatively easy to derive the domain of discourse not covered bythe condition statements of the program units in a feature package. Therun time system algorithms would terminate the feature package when itencounters such a condition. When that happens, it is most likely anexception condition. (The programmer may specify program units that willnormally exit from execution.) The programmer can gain more control onthat exception by writing a program unit as shown in FIG. 21 and put theprogram unit at the bottom of the precedence list of a feature.Alternatively, the programmer may write a feature for such exceptionsand put it at the bottom of the precedence list of a feature package.

Exception handling is an important topic in programming language design.In many software systems, there exists more code for exception handlingthan normal processing. This is an area where the present approach isbetter than conventional programming languages. Since additionallanguage constructs than those already described are not required, thisis not elaborated on in this document.

Note that while the application of the method to telephony is presentedin particularity, the method may be applied to any program especiallythose of large numbers of modules and complexity. Internet applicationsare prime examples of such programs. Altering the functionality ofshopping carts is one such non-trivial programming problem that can makeuse of the present method.

While the language constructs use an event-driven paradigm, the languageis not limited to event-driven applications. As an example, tokensgenerated from the parsing of a text file can be treated as events andanalyzed by programs written in this language.

While particular embodiments of the present invention have been shownand described, modifications may be made by one skilled in the artwithout altering the invention. It is therefore intended in the appendedclaims to cover such changes and modifications which follow in the truespirit and scope of the invention.

1. A method of adding new software features to an application withoutmodifying existing code of the application, the method comprising:receiving a model of the application, the model comprising domainvariables and interface events, where: each interface event defines aset of event types, each event type comprising a unique name and a datastructure, the data structure having qualifying fields used forqualification, and the domain variables are of a Boolean type or adomain data type that includes predicate functions, Boolean variables,and a combination function, receiving features chosen for a featurepackage, the features of the feature package comprising an anchorfeature and a supplementary feature, where each of the anchor andsupplementary features refers to the model and comprises program unitsdefined by a nonprocedural language programming language construct, andwhere each program unit refers to the model and comprises: a conditionpart, the condition part comprising a condition statement and eventstatement; and a body part executed when the condition part is true;identifying interactions between the program units of the anchorfeature; identifying interactions between the program units of thesupplementary feature; where identifying interactions between programunits comprises identifying an interaction condition between a firstprogram unit and a second program unit; outputting the interactionsbetween the program units of the anchor feature and the interactionsbetween the program units of the supplementary feature; enablingresolution of the interactions between the program units of the anchorfeature and the interactions between the program units of thesupplementary feature without modifying existing code of the programunits; identifying interactions between the features of the featurepackage; outputting the identified interactions between the features ofthe feature package; and enabling resolution of the interactions betweenthe features of the feature package without modifying existing code ofthe features.
 2. The method of claim 1, further comprising permitting atmost only one program unit to have a condition part that is true at onetime unless a plurality of program units that have true condition partsalso have a precedence relationship defined by a programmer.
 3. Themethod of claim 1, further comprising permitting only atomic executionof the body part in which events sent from a current body part are keptin an event queue and only after the current body part is exited is thecondition part of another program unit evaluated using latest values ofthe domain variables.
 4. The method of claim 1, further comprisingautomatically checking that: the condition part of at least one programunit of the anchor feature is true with respect to initial values of thedomain variables; each supplementary feature refers to at least oneanchor feature and at least one program unit of each supplementaryfeature interacts with one program unit of every anchor feature to whichthe supplementary feature refers; and the feature package comprises alist of features in the feature package, all features of the featurepackage referencing at least one anchor feature in the feature package.5. The method of claim 1, further comprising specifying precedencerelationships between program units, where the precedence relationshipsare specified within a precedence list or by a collection of programunits.
 6. The method of claim 1, further comprising checking circularinclusion when two features in the feature package transitively includeone another or when two feature packages transitively include oneanother.
 7. The method of claim 1, where enabling resolution of theinteractions among features of the feature package without modifyingexisting code of the features comprises arranging interacting featuresand interacting program units in a precedence list.
 8. The method ofclaim 1, further comprising extending a definition of an existing domainvariable or interface event in an existing model by adding new elementsto the existing definition of the existing domain variable or extendingan existing range of values of the domain variable or qualification. 9.The method of claim 8, further comprising extending the definitionwithout eliminating existing elements or reducing the existing range ofvalues.
 10. The method of claim 8, further comprising extending theexisting model to include all domain variables and interface eventsdefined in the existing model to form an extended model.
 11. The methodof claim 10, further comprising reusing features of the existing modelin a feature package for the extended model.
 12. The method of claim 11,further comprising including the reused features in a feature list of afeature package for the extended model.
 13. The method of claim 12,further comprising preserving precedence relationships among programunits of the reused feature.
 14. The method of claim 13, furthercomprising qualifying reuse of the reused features by modifyingcondition parts of the program units of the reused features such thatlists of events in event statements of the program units include eventsspecified in the qualification.
 15. The method of claim 13, wherein theextended model includes new variables, the method further comprisingqualifying reuse of the reused features by setting the conditionstatements of the features of the existing model to have no dependenceon the new variables when reviewing and executing the features of theexisting model to see if the condition statement are true.
 16. Themethod of claim 1, where each anchor feature in the feature package isindependently developed without requiring changes to other anchorfeatures in the feature package.
 17. The method of claim 1, where eachsupplementary feature in the feature package is independently developedwithout requiring changes to other supplementary features in the featurepackage.
 18. The method of claim 1, further comprising checking forinteraction among program units in the same feature and checking whetherany program unit in a first feature interacts with a program unit in asecond feature when both the first and second features are put togetherin the feature package.
 19. The method of claim 18, further comprisingdetermining interaction between a set of program units by determiningwhether the set of program units wait for the same event and aconjunction of qualification of the set of program units with respect tothat same event is satisfiable, determining that a conjunction ofcondition statements of the set of program units is satisfiable, anddetermining that the set of program units do not have a precedencerelationship.
 20. The method of claim 19, further comprising determiningthat the conjunction of condition statements of the set of program unitsis satisfiable by deriving a disjunctive normal form of a combinedcondition statement of the set of program units, and determining thateach term in the disjunctive normal form of the combined conditionstatement is satisfiable.
 21. The method of claim 20, further comprisingdetermining that the conjunction of each term in the disjunctive normalform of the combined condition statement is satisfiable by groupingliterals belonging to the same domain data type together and evaluatingeach group of literals by using the combination function of the literalsin the group of literals or, when the literals are Boolean variables,looking for contradiction.
 22. The method of claim 19, furthercomprising checking whether the domain variables are independent of oneanother, where a domain variable is independent of another domainvariable if the domain variable is not a function of the other domainvariable.
 23. The method of claim 1, further comprising determining thata program unit of a feature in the feature package is ready forexecution when a condition part of the program unit becomes true unlessa plurality of program units that have true condition parts also have aprecedence relationship, where the precedence relationship is defined ina precedence list included in the feature package.
 24. The method ofclaim 23, further comprising converting all precedence lists to programunits such that the feature package contains only program units.
 25. Themethod of claim 1, further comprising establishing that both thecondition statement and event list of more than one program unit in thefeature package are not true at the same time unless they have aprecedence relationship.
 26. The method of claim 1, further comprisingmaintaining a common state register of truth values of all distinctliterals used in condition statements of the program units in thefeature package and updating the truth values at a desired time duringexecution of the feature package.
 27. The method of claim 1, furthercomprising maintaining an event qualification register of eventqualifications of each event in an event queue of the program units inthe feature package and updating the event qualifications at a desiredtime during execution of the feature package.
 28. The method of claim 1,further comprising generating a first set of static data based on thecondition statements of the program units in the feature package,storing the first set of static data in a first register, generating asecond set of static data based on the event statements of the programunits in the feature package from detection of interaction among thefeatures, and for both the first and second sets of static data:constructing a unit condition register or an event qualificationregister that records values of variables that satisfy each term in adisjunctive normal form of the condition or event, constructing a maskregister to indicate a position of the variables used in the term, anddetermining whether the common state register satisfies the unitcondition register or event qualification register by comparing the unitcondition register or event qualification register to the correspondingmask register.
 29. The method of claim 1, further comprising operatingon an initial state when a run time system is first created, an activestate when the run time system is executing a program unit of thefeature package, and an idle state when run time system is waiting foran event to make a condition part of some program unit of the featurepackage true, invoking the run time system when the run time systemreceives an event or when the program unit of the feature package thatis under execution returns.
 30. The method of claim 1, furthercomprising: initializing a run time system; after initialization of therun time system, executing one of the program units using the run timesystem; after completion of execution of the program unit, checking foran arrival of events, updating domain variables that have been changedas a result of the execution of the program unit, and searching forwhether the condition part of any of the program units has become true;if the condition part of a particular program unit has become true,executing the particular program unit to completion; and if thecondition part of the particular program unit has not become true,waiting for another event until an exit command from a program unit hasbeen executed, wherein the condition part of at most one program unit istrue at one time unless a plurality of program units that have truecondition parts also have a precedence relationship.
 31. The method ofclaim 1, further comprising determining if contradictory precedencerelationships exist among the program units and resolving thecontradictory precedence relationships.
 32. The method of claim 1,further comprising: allocating space and initializing the domainvariables and local variables defined for the feature package, featuresand program units in the feature package; determining a value of acommon state register that contains truth values of all distinctliterals used in condition statements of the program units belonging tothe feature package; determining a set of program units in a currentlist, where the current list identifies a list of program units forwhich the condition statement of the program units is true; setting astate of a run time system as active: if a program unit exists in thecurrent list that is not waiting for any events and executing theprogram unit that is not waiting for any events or if an event queue isnot empty and an event exists in the event queue that matches one of theprogram units in the current list, and otherwise setting the state ofthe run time system as idle.
 33. The method of claim 32, furthercomprising invoking the run time system when the run time systemreceives an event or when the program unit being executed returns. 34.The method of claim 33, further comprising permitting only atomicexecution of any program unit such that the run time system does notstop during execution of a particular program unit and switch to executea different program unit.
 35. The method of claim 34, further comprisingprocessing only one event at a time and determining a priority scheme ofevents to be processed independently.
 36. The method of claim 35,further comprising linking different values of the common state registerto different program units via static analyses thereby enabling the runtime system to learn and remember a current list of program units for aspecific value of the common state register at run time such that therun time system does not determine the current list at a subsequent timethe run time system is active.
 37. The method of claim 1, furthercomprising dividing a domain of discourse defined by the domainvariables and associated predicate functions specified in the model intofinite number of partitions using the condition statements of theprogram units of the feature package, a number of partitions in afeature package being at most a number of program units in the featurepackage.
 38. The method of claim 1, where the anchor feature is anexecutable anchor feature, where the feature package is an executablefeature package, and wherein the executable anchor feature and theexecutable feature package are finite state automata.
 39. The method ofclaim 1, further comprising including an exception condition in at leastone program unit of a particular feature and inserting the at leastprogram unit at a bottom of a precedence list of the particular featureor including a new feature containing the exception condition andinserting the new feature at a bottom of a precedence list of a featurepackage containing the new feature.
 40. The method of claim 1, whereidentifying the interaction condition between the first and secondprogram units comprises: determining whether the first and secondprogram units have a precedence relationship; and if the first andsecond program units do not have a precedence relationship: determiningwhether the first and second program units wait for a common event, thefirst program unit and the second program unit each comprising aqualification and a condition statement associated with the commonevent; for each common event: determining whether a conjunction of thequalifications each of the first and second program units issatisfiable; and determining whether a conjunction of the conditionstatements of each of the first and second program units is satisfiable;identifying the interaction condition as comprising the satisfiableconjunctions determined for each common event; and reporting outputtingthe at least one interaction condition to the programmer.
 41. The methodof claim 40, where each of the condition statements of the first andsecond program units and each of the qualifications of the first andsecond program units is a simplified predicate formula, and wheredetermining whether a conjunction of two simplified predicate formulas,M and N, is satisfiable comprises: deriving a disjunctive normal formD(M) of M; deriving a disjunctive normal form D(N) of N; for each termin D(M), determining whether the conjunction E(M, N) (i) between eachterm in D(M) and each term in D(N) is satisfiable, where i representsthe i^(th) conjunction; and for each satisfiable conjunction E(M, N)(i), outputting the satisfiable conjunction E(M, N)(i).
 42. The methodof claim 41, where determining whether the conjunction E(M,N) (i)between each term in D(M) and each term in D(N) is satisfiablecomprises: for each E(M, N)(i), group literals belonging to a samedomain data type together to form a group of literals; evaluating eachgroup of literals by: using respective combination functions of thegroups of literals; or identifying contradiction where the group ofliterals comprises Boolean variables; identifing the conjunction E(M,N)(i) as satisfiable if any group of the group of literals evaluates to aFALSE value in response to evaluating.
 43. The method of claim 42,further comprising determining whether values in a first registersatisfies a BOOLEAN formula M, in which the first register contains bitsthat each represent a value of a distinct BOOLEAN variable, a secondregister has the same dimension as the first register, each bit of thefirst and second registers in the same position represent the samevariable, the second register records values of variables that willsatisfy the BOOLEAN formula M, and a third register represents variablesused in the formula M with TRUE and FALSE otherwise, through Algorithm 4and applying Algorithm 4 to determine whether a common state register(CSR) satisfies a unit condition register (UCR) and an event stateregister (ESR) satisfies an event qualification, wherein Algorithm 4comprises: performing a bit by bit logical AND operation between thefirst and third registers, and recording the result into a temporaryvector of the same dimension such that at the end of the bit by bitlogical AND operation, the temporary vector has a value of FALSE onevery variable not used in the formula and the same value as in thefirst register on every variable used in the formula; performing a bitby bit logical EXCLUSIVE OR between the temporary vector and the secondregister; and establishing that the first register satisfies the BOOLEANformula M only if the temporary vector and the second register matchexactly.
 44. The method of claim 1, providing a run-time system formanaging execution of the feature package including features and programunits of the feature package, where providing a run-time systemcomprises: allocating space and initializing the domain variables andlocal variables defined for the feature package, and for the featuresand program units of the feature package; initialize a current stateregister, the current state register identifying a run-time systemstate; determining a current list, where the current list identifies alist of program units for which the condition statement of the programunits is true; determine whether any of the program units in the currentlist are waiting for an event; if a program unit in the current list isnot waiting for an event: set the run-time system state to an activestate; and execute the program unit; if the program units in the currentlist are each waiting for an event: determine if an event queue includesan event that satisfies an event statement of a program unit in thecurrent list; if the event queue includes an event that satisfies theevent statement of a program unit in the current list: set the run-timesystem state to an active state; and execute the program unit; if theevent queue does not include an event that satisfies the event statementof a program unit in the current list: set the run-time system state toan idle state.
 45. The method of claim 44, further comprising invokingthe run time system comprising: receiving an event; assigning thereceived event to the event queue if the run-time system state is set tothe active state; if the run-time system state is not set to the activestate: determining whether the received event satisfies an eventstatement of a program unit in the current list; if the received eventsatisfies an event statement of a program unit in the current list,setting the run-time system state to the active state; and executing theprogram unit in the current list for which the event statement of theprogram unit is satisfied by the received event; otherwise, assigningthe received event to the event queue.
 46. The method of claim 44,further comprising invoking the run time system comprising: determiningwhether, upon execution of a program unit, any domain variables of theprogram unit have been updated; and if any domain variables of theexecuted program unit have been updated: updating the current stateregister; updating the current list; terminating the run-time system ifthe current list is empty; and if the current list is not empty, or ifno domain variables of the executed program have been updated: settingthe run-time system state to the idle state if the event queue is empty,otherwise: determining if the event queue includes an event thatsatisfies an event statement of a program unit in the current list;setting the run-time system state to the idle state if the event queuedoes not include an event that satisfies an event statement of a programunit in the current list; and if the event queue does include an eventthat satisfies an event statement of a program unit in the current list,setting the run-time system state to the active state and executing theprogram unit.
 47. The method of claim 1, wherein the condition statementis a Boolean formula of Boolean domain variables and predicates of othertypes of domain variables and the interface event includes a Booleanformula of the qualifying fields of the interface event and the bodypart includes operating on the domain variables and sending events. 48.The method of claim 1, wherein the feature package further comprises alist of program units contained within the feature package.
 49. Themethod of claim 1, wherein the feature package further comprisesprecedence lists of features and program units contained within thefeature package.
 50. The method of claim 1, further comprising reusingfeatures and feature packages in an extended model containing new domainvariables by modifying condition parts of the program units in thefeatures and feature packages to include conditions containing the newdomain variables.
 51. The method of claim 1, further comprisingdetermining whether the condition statement of a particular program unitis satisfied by a bit by bit comparison between two registers.
 52. Themethod of claim 1, further comprising analyzing the feature package as afinite state automata, where the feature package is an executableprogram.
 53. A method for developing an executable applicationcomprising a well-formed feature package, the method comprising:obtaining a model of the application; and obtaining the well-formedfeature package comprising an anchor feature and a supplementaryfeature, where obtaining the well-formed feature package comprises:obtaining the anchor feature, the anchor feature comprising a first anda second program unit defined by a nonprocedural programming languageconstruct, where the anchor feature is developed based on the model, andwhere each program unit comprises: a condition part, the condition partcomprising a condition statement and an event statement; and a body partexecuted when the condition part is true; determining whether the firstand second program units have a precedence relationship; and if thefirst and second program units do not have a precedence relationship:determining whether the first and second program units wait for a commonevent, the first program unit and the second program unit eachcomprising a qualification and a condition statement associated with thecommon event; for each common event: determining whether a conjunctionof the qualifications each of the first and second program units issatisfiable; and determining whether a conjunction of the conditionstatements of each of the first and second program units is satisfiable;and identifying an interaction condition between the first and secondprogram units as comprising the satisfiable conjunctions determined foreach common event; and outputting the interaction condition identifiedbetween the first and second program units; obtaining the supplementaryfeature, the supplementary feature comprising a third and a fourthprogram unit defined by a nonprocedural programming language construct,where the supplementary feature refers to the anchor feature and atleast one program unit of the supplementary feature interacts with atleast one program unit of the anchor feature; identifying an interactioncondition between the third and fourth program units; and outputting theinteraction condition identified between the third and fourth programunits.